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USAGE BASED PRICE PLANNING 



This invention relates to networks and network usage, and more particulai-ly to 
network pricing plans. 

5 BACKGROUND 

Service providers are in constant competition with each other to find new 
ways of attracting customers. An increasing number of service providers have 
entered the ever-growing world of e-commerce that demands high quality of service 
and quick turn-around time. E-commerce service providers offer a wide range of 

10 semces that involve direct on-line services such as network access from Internet 
Service Providers (ISP) and Network Service Providers (NSP) and more traditional 
sei-vices such as e-commerce auctioning to furtlier theii* service. For example, many 
on-line auction services use e-commerce to help sellers put tiieir products up for 
auction while a number of buyers enter a bidding war leading to an ultimate purchase 

1 5 between the high bidder and the seller. All of these services found on-line mvolve 
some sort of usage, whether tliat usage be time spent on-line or bandwidtli used 
during the time on-line. In particular, ISPs and NSPs provide network access to users 
who range from an individual web suifer who may be on-line a few hours at a time to 
large corporations who may be on-line 24 hours a day, seven days a week and who 

20 require a large amount of bandwidth. 

Whether an individual surfer or a large coiporation, customers attempt to find 
tlie best possible deals to minimize the cost of being on-line. ISPs and NSPs typically 
offer pricing plans to their customers tliat involve a charge per unit time, whether that 
be an hourly charge or an unlimited montlily charge. In addition, many ISPs and 
25 NSPs have an ''acceptable use" condition for using their service. For example, 
customers cannot send "spam'' emails over the linlc provided by the ISP or NSP. 
Another condition is that a customer cannot hook up a server to the linlc because the 
server can use an unacceptable amoimt of bandwidth. However, ISPs and NSPs 
typically are not equipped to monitor violations of these conditions. Fuitliermore, 
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increasing ISP competition drives the marketing departments of the ISPs to come up 
with quick changes m the ISP pay plans to meet tlie market demand. 

SUIMMARY 

5 In general the inventions features a method and apparatus for representing 

pricing plans for on-line services, in particular for Internet and network services. 

In one aspect, tlie invention features a method of determining a billing-cycle 
price for network services, including estabhshing a price plan for each of a pluraUty 
of clients, wherein the price plan sets a price per use unit, collecting use data ftom the 
10 plurality of clients, sorting the use data into data groups corresponding to each of the 
plurality of clients; and processing the data groups to determine the biiling-cycle price 
for each of the plm*ality of clients, wherein the billing-cycle price is calculated from 
use data and the price per use unit. 

In an implementation, the price per use unit is determined by: time that each of 
1 5 the clients used the network services, network bandwidth that each of the clients used, 
network content that each of the clients used, email that each of the clients generated 
on the network, electronic storage space used by each of the clients, web space that 
each of the clients used, multimedia usage that each of the clients used, or Internet 
protocol addresses in use by each of the clients. 

20 In another implementation, the method farther includes allowing each of the 

plurality of clients to choose a price plan that includes more than one price per use 
unit, calculating a billing-cycle price for each price per use unit, presenting each 
billing-cycle price to each of the clients, allowing the client to choose the billing-cycle 
price that is the most cost efficient, ti'ansmitting a bill presentation template to each of 

25 tlie clients, wherein the bill presentation template is transmitted to a client web 

browser connected to the network, and displays chai'ges presentation mciured duiing 
the billing cycle. 

In another aspect, the invention features a method of developing a price plan 
for services on a display, including providing an interface on tlie display, providing on 



2 
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the interface images adapted to receive price plan criteria and receiving in tlie images 
price plan criteria. 

In an implementation, the images on the interface are graphical user interface 
(GUI) screens. 

5 In another implementation, providing the images comprises presenting tlie 

GUI screens in an order to present price plan criteria input options for genei*ating the 
price plan to the user. 

In another implementatioiv the method farther provides generating the price 
plan into source code and compiling the computer code into machine-readable code. 

10 hi another implementation. Hie method provides supplying the price plan data 

to at least one of the soinrce code and the machine-readable code to calculate a charge 
for the services. 

hi still another implementation, the images on the interface are graphical 
elements representing components of the price plan and providing the images includes 
15 . arranging the graphical elements on the display that graphically represents the 
calculations for the price plan charge and providing intercormections among the 
graphical elements to provide price plan data flow patlis. 

In yet another implementation, the method further uicludes storing the 
aiTangement of grapliical elements as source code, compiling the source code into 
20 macliine-readable code and supplying the price plan data to at least one of the source 
code and the machine-readable code to calculate a charge for the services. 

In another aspect, the invention features method of billing for services, 
including determining a price plan that charges a client for services based on use, 
keeping a record of data of the client's use of the services, deteraiining a charge for 
25 the services based on the price plan and the record of the client's use of services and 
presenting a bill for the sei-vices. 

In an implementation, detemuning the price plan includes establishing tlie 
type of use for which tlie client desires to be billed, establishing a unit of cost for the 
type of use and generating a customized price plan template that reflects the type of 
30 use and the unit of cost and is adapted to receive the record of data. 
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In another implementation, deteraiining tlie charge for the services, comprises 
using the customized price plan template to calculate the service chaige by processing 
the record of data based on the type of use and the unit of cost and presenting the bill 
for services includes generating a bill presentment template adapted to present tlie 
5 record of data, tlie typQ of use, the unit of cost, and the service charge and presenting 
the bill presentment template to tlie client. 

In still anotlier aspect, the invention featui'es a price plan network system, 
including at least one data collector adapted to collected client data from the network, 
a database coupled to the data collector, a price plan builder coupled to die database, 

10 the price plan builder having a user interface a first software module having a price 
plan template adapted to direct a user through a series of steps to develop a price plan, 
a second software module coupled to the first software module, the second module 
including a plurality of components adapted to be intercoimected to build a price plan 
source code, an object builder adapted to compile the source code into machine 

1 5 readable code and a bill presentation module coupled to the database. 

In an implementation, the system fiirther includes a rater coupled to the 
database, adapted to be controlled by the machine-readable code to process the client 
data mto billing data. 

In another implementation, the bill presentation template includes a user 
20 interface adapted to display the client data and the billing data 

In yet another aspect, the invention features a price plan development and 
presentation system including means for building a price plan based on a client's use 
of semces, means for collecting raw use-based client data, means for processing the 
use-based client data using the price plan and means for presenting the raw and 
25 processed use-based client data to the client. 

In another aspect, tlie invention features a network service provider metliod of 

chai-ging a cUent for connecting the client to the network i ncluding developing a price 

plan agi*eement between the semce provider and client, tlie agreement stating that the 

sei-vice provider provides a comiection to the network in exchange for compensation 

30 ft-om the client, the compensation being calculated based on the client's use of the 

network, providing to the client a connection to the network, collecting use-based data 

4 
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from the network, processing the use-based data based on tiie price plan and 
presenting tlie charges to the cUent. 

hi another aspect, the invention features a metliod of creating a price plan in a 
graphical program on a computer having a memory, a display, a user mput and a 
5 processor, including storing in memory a plurality of executable functions 

representing aspects of the price plan, assembling a data flow diagram on the display 
in response to user input to specify the price plan, the data flow diagraiTi including 
function icons corresponding to the respective ones of the executable functions and 
generating an executable program from the data flow diagram. 

10 In an implementation, the method fiirther includes receiving price plan data in 

the executable program, processing the price plan data to calculate charge output data, 
creating a bill presentation template on a web page and providing the charge output 
data to the bill presentation template. 

' The details of one or more embodiments of the invention ai e set forth in the 
15 accompanying drawings and tlie description below. Other features, objects, and 

advantages of the invention will be apparent from the description and drawings, and 
from the claims. 

DESCRIPTION OF DRAWINGS 

20 Fig. 1 illustrates a network access system 

Fig. 2 illustrates an implementation of a billing system. 

Fig. 3 illustrates a process flow chart of an implementation of a biller/rater. 

Fig. 4 illusti-ates a process flow chart of an implementation of a graphical price 

plan. 

25 Figs 5 A-5C illustrate screenshots of an unplementation of a price plan wizard. 

Fig. 5D illustrates a flow chart of an implementation of price plan 
development using a price plan wizard. 

Fig. 6 A illustrates a flow chart for an embodiment of price plan development. 

Fig. 6B illustrates a process flow chart of primitives used in a price plan. 

5 
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Fig. 6C illustrates a screen shot of an embodiment of a price plan builder. 

Fig. 7 A illusfrates a flow chart for an implementation of a diagnostic i*un time 
process. 

Fig. 7B illustrates a flow chail for an implementation of a process to build 
5 object code. 

Fig. 8 illustrates a flow chart for an implementation of a rating engine process. 

Fig. 9 illustrates a flow chait for an implementation of a billing presentation 
process. 

Fig. lOA illustrates a screen shot of an implementation of a blanlc bill 
1 0 presentation template. 

Fig. lOB illustrates a screen shot of an implementation of a bill presentation 
template after it is provided with billing data. 

Like reference symbols in the various drawings indicate lilce elements. 

1 5 DETAILED DESCRIPTION 

Fig. 1 illustrates a network access system 100. Several devices 110, such as 
personal computer stations, may desire access to a network 120, such as the hitemet. 
A sei-vice provider 130, such as an NSP or ISP can provide network access tlirough a 
series of comiections 150, such as telephone modems or cable modems, linlcing tlie 
20 devices 110 to the network 120. The devices 110 may desire to search tlie network 
120 for information or gam access to any one of a vaiiety of servei-s 140. Hie service 
provider 130 typically imposes a charge to link the devices 1 10 to tlie network 120. 
Therefore, the service provider 130 also collects data related to billing the devices 1 10 
for connection to the network 120. 

25 . Fig. 2 illusti-ates an implementation of a billing system 200. A client 210 may 

want to access a network 220 such as tlie Internet. The client 210 can obtain tliis 
connection thi'ougli a service provider 230. If necessai7, a virtual private network 
(VPN) module 245 is used to provide a private connection between the client 210 and 
the network 230. The client 210 typically signs up v/ith the service provider 230 

6 
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through a registration/provisioning engine 240. Using tlie registration engine, the 
ser\'ice provider 230 can queiy the cHent 210 for pertinent information concerning the 
client such as method of payment for seivices as well as a price plan that the client 
210 desires to use. The client 210 can have a predetennined price plan that 

5 determmes how the client 210 is billed for the connection to the network 220. hi a 
typical embodiment, the price plan is use-based. Use-based price plans ai*e discussed 
ill detail below. A collector 235 is used to collect the use-based data. The collector 
235 is adapted to collect any of the use-based data, such as tune-stamps for tune 
based-usage, bandwidtli used for bandwidth-based usage, and number of emails and 

10 size of the emails for email-based usage. Typically, time stamps are collected for all 
types of data so that price per unit can be determined by time when use is incurred. 
For example, different price units can be applied on bandwidtli Use depending on the 
time of day. In otlier embodiments, the collector is adapted to collect any data 
depending on the usage-based plan that the client 210 has chosen. Also, the collector 

15 235 is used to manage the addresses of the numerous clients attached to the service 
provider 230, as well as providing application switches to the individual clients, hi 
one embodiment, the collector utilizes Radius software to manage real time swdtcliing 
between clients to ensure tliat the proper use-based data is charged to the proper 
client. In another embodiment RM0N2 software is utilized. The principal ftmction 

20 of the collector 235 is to collect and resolve usage data into accounts from various 
usage information sources such as RADIUS and RM0N2 devices. The usage 
information sources are not part of the collector 235. The collector 235 does not 
typically have other fimctions such as managing client addresses, application switches 
and tlie like. 

25 Referrmg still to Fig, 2, a biller/rater 250 is used to calculate the charges tliat 

the client 210 incurs wliile connected to tlie network 220. The biller/rater 250 is also 
used to present the bill to the client 210 after a billing cycle. Billing and rating 
fimctions of tlie biller/rater 250 are discussed in detail below. The biller/rater 250 is 
used in close conjunction with the collector 235. Once data is collected, the 

30 management software is used to direct the appropriate billing chai'ges the biller/rater 

250 in order to calculate the coirect charges which are billed to the client 21 0. The 

chai'ges billed to the client 210 are dependent on tlie price plan for which the client 

7 
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signed. An account management module 255 is used to manage use-based data 
collected from the client 210 tlu-ough the collector 235. The rater 250 ensures that the 
client 210 is charged only for the network usage incurred by the client 210 and not a 
different client. The account management module 255 works in close conjunction 

5 with the collector 23 5 and die biller/rater to store and manage the incurred charges. A 
market intelhgence module 260 monitors and processes client 210 usage as well as 
price plans and client usage from other service providers on the network 220 to 
deteimine new marketing strategies. A payment/fmaiiciai module 265 is used to track 
payments made by the client 210 and any other related financial matters. A database 

10 270 is used to store client 210 information as well as price plans that the service 
provider 230 offers and a variety of other service provider-related information. 

The client's 210 usage may be based only on time such as an houily or 
montlily charge or may be based on some other usage-related basis such as 
bandwidth, content, email, storage web space, active internet protocol (IP) addresses, 

15 downloaded movies, or downloaded music. For example, the client may be a server 
that receives a large volume of traffic on a daily business. A service provider 230 
may want to charge a server-client with a large traffic volume by bandwidtli in this 
situation. In another example, the client 210 may be billed only on the number of 
emails that are sent between the client 210 and the network 220. The client can have 

20 a predetermined plan that outlines a how the client is charged for the network usage. 
Typically, chai'ges are incurred by uses including but not limited to time, bandv^dth, 
content, email, electronic storage, web-space used, multimedia usage such as video 
and audio downloads, and IP addresses in use. For example, a client may choose a 
plan that bills the client for time spent on tlie network. Under a time-based plan, the 

25 client can be charged either by the hour or minute or can be charged once per week or 
month for unlunited minutes or hours. If the client is rimning a server on the network, 
the client may choose a plan that charges the client for the bandwidth used regardless 
of the time spent on the netv^'ork. Under another plan, the client may be chai-ged by 
the number of emails generated, whether sent or received. The email-based plan may • 

30 also include a further stipulation tliat tlie emails sent and received have to be of, at 

most, a certain size, or a further charge is incurred. For example, each email may be 

limited to 3 Megabytes, and for every Megabyte above 3 Mbytes, a fuitlier chai'ge is 

8 
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incurred to talce into account additional bandwidtli used for the email. Still another 
plan can allow a client to download movies or sound files from web sites at a ceitain 
price per movie or soimd file. In one embodiment, tlie client can choose an omni- 
inclusive plan that encompasses several of the above-described plans. One goal of the 

5 omni-inclusive plan is to track chai'ges for each of the plans included in tlie onrni- 
uiclusive plan. At the end of the billing cycle, the client can then be presented with a 
template including each charge of each plan. The client can tlien choose to pay for the 
plan that is the least expensive. In tliis way the client can use several plans on a ti-ial 
basis and deteimine which plan suits the chent the best. In an implementation of the 

10 omni-inclusive plan, tlie client is charged an additional cost each billing cycle for 
being able to decide among seveml plans. After several billing cycles, the client can 
opt out of the omni-inclusive plan and decide to remain with only one plan. For 
example, if anNSP offers several use-based plans such as time, bandwidtli, email and 
web space, a client can choose to track charges for each of the plans under an onmi- 

1 5 inclusive plan. At the end of a billing cycle, tlie client is presented witli a bill that 
shows a charge for each of the time, bandwidth, email and web spaced used. The 
client can determine, for example, that the time-based charge was the least expensive 
and chooses to pay only the time-based charge. Tlie client is also charged an 
additional cost to have tlie ability to choose among the plans. Thereafter, the chent 

20 210 can then choose to be charged only under the time-based plan. 

The billing and rating fbnctions mentioned above are mterrelated with one 
anotlier and encompass both service provider 230 and client 210 interaction. Fig. 3 is 
a process flow chart illustrating an implementation of the operation of the biller/rater 
250. The service provider 230 has tlie ability to gi-aphically define a price plan with a 

25 series of sofbA'are ''primitives" which ai'e comiected together in a grapliical 

programming environment, such as Visio®. Primitives and their ftinctionality are 
discussed in detail below. A graphical price plan 3 1 0. is created by the service 
provider 230. The client 210 uses a client browser 330 in order to sign on to the 
network 220 and perform network functions such as web surfing through the service 

30 provider 230. The client browser 330 also is used to initially choose a price plan and 

to have the billing chai*ges presented to the client 210 at the end of a billing cycle. 

Ai'ound the same time that the price plan is defined using the graphical price plan 310, 

9 
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a bill presentation template 320 is also defined. The bill presentation template 320 is 
typically determined by the price plan chosen by the client 2 10. However, the bill 
presentation template can be modified to meet the needs of the client 210 or the 
service provider 230. As charges accrue, the collector 235 gathers the chai'ge data and 

5 transfers it to a data repository 360. The charge data is fransfeiTcd to a rating engine 
340 and to the web bill presentment. Tlie rating engine 340 is coupled to the 
grapliical price plan 310. The rating engine 340 uses the price plan primitives from 
the graphical representation to process the charge data. Depending on the price plan 
chosen by the client 210, tlie data gatliered by the collector may be different for 

1 0 different clients. For example, if the client 2 1 0' chose a time-based price plan, tlien 
tlie rating engine would typically acquire time stamp information from the gathered 
charge data. If the client's price plan were based on bandwidtli used, then tlie rating 
engine 340 would acquire data indicating the number of bytes used by tlie client 210 
during the network session. If the client's price plan were based on the number and 

15 size of the emails sent to and received from the network, tlie ratmg engine 340 
processes only the email data. 

The data repository 360 is also coupled to the web bill presentment 350 so that 
the client can also view the "raw usage" before they are processed by tlie rating 
engine 340. The web bill presentment 350 is the web interface with the client browser 

20 330 for bill viewing. The rating engine 340 stores the processed use data in an 
account database 370, wliich is also coupled to the web bill presentment 350. The 
account database 370 stores all of the client's billing pertinent information such as a 
chosen price plan. The rating engine 340 is also coupled to a bill details database 380, 
which stores all of the processed data. Tlierefore, the client 210 can view and 

25 compare the raw use data with the processed use data. If the client 2 10 has chosen 
more than one price plan or all of the price plans as discussed above, the client is able 
to view all raw data and all processed data on the web bill presentnent 350. The bill 
presentment 350 enables a client 210 to make a decision on which price plan works 
best for the client's needs. 



10 
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Billing aiid Rating 

Hie graphical price plan 310 is an aggregate of several components tliat the 
service provider 230 uses to build a price plan for the client 210. Fig. 4 illustrates a 
process flow chart of an implementation of the gi'aphical price plan, hi tliis 

5 implementation, the aggregate of components that malce up tlie grapliical price plan 
are a rating plans database 410, a rating primitives database 420, and plan object 
builder 430 and a plan objects database 440. The rating primitives database 420 is a 
storage medium for the primitives that are the softwai-e components used to build a 
price plan. Primitives are programmed to serve a specific function. Primitives can be 

10 programmed for virtually any function that is needed for the price plan. A description 
of primitives and theh function is discussed below. A rating plans database 410 
contains graphical programs made from intercomiecting a series of primitives from 
the rating prunitives database 420. The rating plans can be viewed as graphical 
source code. A plan object builder 430 is the compiler for tlie graphical soui'ce code. 

15 The graphical source code is compiled and stored as an object file in a plan objects 
database 440. The rating engine 340 can access, from the plan objects database 440, a 
plan object that corresponds to a plan the client 210 has chosen. The rating engine 
440 then executes the plan object code and processes the raw data from die collector 
235. 

20 While primitives are tlie fiuidamental building blocks of a price plan, building 

a price plan has several levels of complexity. For a non-tecliiiical person such as a 
marketing manager and salesperson, a high level editor is needed that allows a price 
plan to be developed quickly without requiring a high level of teclinical savvy. Figs. 
5A-5C illustrate screenshots of an implementation of a price plan wizard. Fig. 5 A is a 

25 screenshot 500 of an implementation of an introductory screen for a price plan wizard. 
The screenshot displays textual instructions 505 to guide the developer thiough the 
price plan building process. Fig. 5B illustrates a screenshot 510 of an implementation 
of a screen in which a price plan developer can choose what land of charges 5 1 5 inciu 
in the price plan. As seen in the figiue, a simple fixed charge 5 1 5a, such as one 

30 monthly charge, can be implemented in the price plan. A recuiTmg charge 5 1 5b such 
as a per minute charge can also be incuned. A use-based charge 515c can also be 
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incurred. The use-based charge 515c is the charge for such usages as bandwidth, 
email, and other usages as described above. Fig. 5C ilKistrates a screenshot of an 
implementation of a fixed charge screen 520. Using this screen, the'deveJoper of a 
price plan can impose a one-time charge on a client 21 0 for a set up charge or other 
5 type of one-time charges. Using the price plan wizard, a developer can quickly 
customize a price plan for a customer witliout burdensome programming. 

Fig. 5D illustrates a flow chart 530 for a typical embodiment of a price plan 
development using a price plan wizard. When the price plan wizai-d is initiated it is 
fu-st determined 535 if there are any one-time charges. If there are, then the developer 

1 0 provides 540 the details, that is, the cost and conditions of the one time charge. The 
next query is whetlier there ai'e any recurring 545 chai ges. If there are recurring 
chai'ges, then the developer provides 550, the amount and frequency of those 
recurring charges. Typically, the recuning charges will be a unit charge per minute, 
hoiu* or month. The next query 555 is whether or not there are any use-based charges. 

15 How^ever, in one implementation, there can be a recurring monthly charge as well as 
an additional chai'ge for bandwidth used, email generated and received or any other 
use-based charges as discussed above. If there are use-based charges, then the 
developer provides 560 tlie description and amount of the use-based charges. In a 
typical plan, there may be some free usage. Therefore it is queried 565 whetlier or not 

20 there is any free usage. If there is free usage, then the developer provides 570 the 

details of the free usage. In one embodiment, the free usage may be a certain number 
of free connection hours. In anotlier embodiment, the free usage may be use-based 
(i.e., bandv/idth, email etc.) Another typical query 575 is whether there are any peak- ' 
related charges. If there are peak-related charges then the developer provides 580 the 

25 details of the peak-related charges. 

The price plan wizai"d then ceases the queries and a series of primitives are 
comiected and compiled witliout interaction from the developer. Price plan object 
code is then available in tlie price plan database 41 0 for execution. The price plan 
graphical source code is typically stored as XML code. 
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While tlie liigh level price plan wizai'd is a vital tool for non-technical agents 
of the service provider 230, it laclcs fmlher the flexibility of directly connecting 
primitives which can provide fiiither extensibilit>' for price plan development. 

As mentioned above, in one embodiment, a gi-aphical programming progi'am 

5 such as Visio® is used to build a price plan by interconnecting numerous primitives 
as a flow. In such an embodiment, a service provider agent can build a price plan 
quickly and efficiently using this price plan editor. For example, a marketing 
manager in an ISP company such as can quickly respond to changes that competitors 
have made in a price plan by opening tlie price plan wizai'd or having one of the 

10 programmers use a price plan editor to connect a series of primitives to match the 
price plan offered by a competitor. As another example, if a salesperson for an ISP is 
discussing a deal with a large corporation, the salesperson can quickly and efficiently 
make changes to a price plan using the price plan wizard. If the lai*ge corporation 
does not like any of tlie price plans that tlie salesperson can create using the price plan 

1 5 wizard, the salesperson can contact an engineer or programmer to use the primitive 
editor to create a more suitable price plan. The programmer can attempt to use the 
existing primitive in the rating primitives database 420 existing primitives from the 
rating primitive database 420. If the existing primitives ai*e not sufficient, the 
salesperson can communicate the desires and needs of the corporation and the 

20 programmer can write a new primitive that meets tlie needs of the corporation! The 
flexibility and extensibility of primitive programming allows sales people, marketing 
managers and programmers to work independently or in conjunction to respond to 
marketing and sales needs in a competitive environment. In an embodiment, the 
primitive prograrmning language can be any open platform language such as Java®, 

25 C, C++ and Visual Basic®. 

Many references have been made to primitives. Tlie discussion now addresses 
primitives and their fluictionality. The follov/ing table represents a subset of 
categories of a number of primitives and a short description of the function of each 
primitive as it can be used in any of several implementations: 

30 
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Category 


Primitive 


Description 


Accumulators 


Monthly Accumulator 


Accumulate usage on a Monthly basis 


BillingCycleAccumulator 


Accumulate usage on a billing cycle basis 


Weelcly Accumulator 


Accumulate usage on a weelcly basis 


Daily Accumulator 


Accumulate usage on a daily basis 


Filter 


ThresholdFilter 


Filter usage based on a tlureshold value 


DailyTimeFilter 


Filter usage based on time of day j 


WeelclyTimeFilter 


Filter usage based on time of day and day of week 


UsageTypeSelector 


Select usage type | 


SpecialDaysTimeFilter 


Filter based on designated days 


UsageTypeClassifier 


Derive new usage type 


Non-Usage 
Based 


OneTimeCharge 


Set up chai ge 


BillingCycleRecurringCharge 


Recurring charges based on billing cycles 


MonthlyRecurringCharge 


Monthly charge 


Rater 


StepRater 


Rate based on steps having a multiplier and 

constant 


Adder 


Sum all charges 


Specialized 
Rater 


CostResponsibilityMatrix 


NetCountant Enterprise Cost responsibility matrix 


E164DialPlaiiRater 


Calculate E.164 based phone charges 


TaxCalculator 


Calculate applicable county/state/local taxes 


CunencyConverter 


Convert from one currency to another 


IptoLocationlv4apper 


May any given IP address to geographical location 


Account 
Interface 


AccountFinalizer 


Post charges/credits to primary account 


SecondAccountFinalizer 


Post chai'ges/credits to a second account 



Table 1. 
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Primitives can be programmed directly in a primitive programming 
enviromnent, wliich typically involves adding primitives and interconnecting 
primitives using typical data flow progi amming. If there ai*e no primitives that meet 
5 the needs of a particular price plan, a programmer can create a new primitive by 
traditional programming methods such as Java®, C, C-H- and Visual Basic®. 

Primitives are also connected while using the price plan wizard. As discussed 
above, using the price plan wizard, tlie developer chooses the price plan options in the 
price plan wizard screens. During this development, a price plan generator, which is 
1 0 pait of the price plan wizard, is comiecting a number of primitives together according 
to the choices made in the price plan wizard. Either way, primitives are fundamental 
building blocks of the price plan. 

Fig. 6 A illustrates a flow chart of an implementation of grapliical 
programming using primitives to develop a price plan. Similai' to the price plan 

1 5 wizard described with respect to Figs. 5A - 5C, it is first determined 605 whether 
there are any one time charges. If there ai'e, the necessary primitives are added 610in 
the programming editor to reflect the one time charge. It is next determined 615 if 
there are any recurring chai ges. If there are recurring charges, primitives are added 
620 to reflect these charges. It is next determined 625 if there ai'e any use-based 

20 charges (as discussed above). Once again, if there are any use-based charges, 

primitives are added 630. If there is any free usage 635, the appropriate primitives are 
added 640. There may be a charge difference for on-peak and off-peak usage 645, 
and primitives are appropriately added 646 to reflect those differences in charges. 
Simple adding prhnitives and account management primitives are also added 647. 

25 Fig 6B illusti-ates an implementation of a price plan developed by 

interconnecting primitives using a price plan editor. As discussed above with respect 
to Fig. 4, the primitive programming environment is the graphical source code that the 
developer uses to ultimately create a plan object for execution by the rating engine 
340. The example used in Fig. 6 is a simple price plan that consists of a $10 one-time 

30 set-up charge and a single monthly charge of S20 with monthly billing at S20/montii. 
The plan includes 100 free connection hours. After 100 hours peak time (7PM- 
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midniglit), the plan bills at $l/hx. In addition, off-pealc time (midnight - 7PM) is 
billed at $0.50/lu for the first additional 100 houi'S, then $0.25 thereafter. 

Each primitive in the price plan is programmed with the necessary data as 
described. A OneTimeChaige primitive 655 is programmed to incui* a set-up chai'ge 

5 of $10 only the fust time that the corresponding plan object code is executed, and 
includes software logic to prevent multiple recun*ences of the one time charge. 
Thereafter, the OneTimeCharge primitive 655 does not execute. Rumring in pai*allel 
to the OneTimeCharge primitive 655 is a RecurringCharge primitive 660 that incurs 
the chaige of $20 for every passmg montli. Tlie Recun'mgCharge primitive 660 uses 

10 tlie data gathered by the collector 235 in order to obtain time stamp data 65 1 to 

deteraiine when a time period of one month has occun-ed. A FreeStepRater 665 is a 
primitive programmed to "step up'Vtlie nimibers of hours up to a specified number of 
hours. It is progranmied with data 667 in order to cease stepping, in this example, at 
100 hours. Two DailyTimeFilter primitives 670, 679 are used to allow tlie program 

1 5 data to flow one way or another. If the data is gatliered during pealc hours of 1 9:00 to 
24:00, then the data is pennitted to flow tluough the DaibTimeFilter 670, Data 671 is 
prograimned into the DailyTimeFilter 670 to specify the time range that data is able to 
flow. During tliese peak hours data does not flow through the DailyTimeFilter 675 
which is programmed with data 676 that only allows data flow during tlie hours of 

20 00:00 and 1 8:59. A corresponding PeakStepRater primitive 680 is progi*ammed to 
determine the cost of usage during the peak hours. As discussed above, the price 
plan in tliis example charges $1/ hi' of peak time usage. MultipHer data 681 is 
programmed into the PeakStepRater primitive 680. These chai'ges only apply after 
the 100 free hom's have passed as set by FreeStepRater 665. Similai'ly, if the client 

25 210 is accessing the network during off peak hours, a chaige of $0.50/b- applies if 1 00 
hours of off-peak time has not yet been attained, and a charge of $0.25/lir applies if 
the number of off-peak hours exceeding 100 has been attained. However, if at the 
FreeStepRater 665, it is determined fliat the number of hours has not exceed the initial 
100 houi-s (whether peak or off peak), the usage data is caused to be blocked firom the 

30 DailyTimeFihers 670, 675 and the StepRaters 680, 685 and no cost data flows directly 

to an adder 690 through these patlis because the FreeStepRater 665 will have no 

output to trigger the succeeding primitives. The adder 690 is progiammed to add all 
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of the charge data tliat is available to-it. After tlie Adder 690 executes, the data flows 
to an Account Finalizer primitive 695 that transfers the data to the account 
management module 255 or tlie account database 370. The charge data at this time is 
$0 unless it is the first time the client 210 is using the account, and the one time 
5 charge is incun-ed from the OneTimeCharge primitive 655. 

hi the above-described graphical progi'amming implementations, several 
primitives are used. Some primitives are executed in paiallel when data is available 
to them. However, for many programming sequences, primitives can be required to 
run in series. The systems and techniques described are fault tolerant so that one 

10 primitive does not execute until it has the data it needs either from the collector or 
from the output of another primitive. This fault-tolerance prevents errors from 
occurring in a situation where a primitive tries to execute before it has its proper data. 
The systems and techniques described imply a proper execution sequence of the 
primitives to make sure that input data is available from the preceding primitive 

15 before the current primitive is executed. This-can be accomplished by performing a 
topological sort on the price plan graph treating the primitives as nodes and 
interconnections as directed edges. For example, in the price plan example described 
above with respect to Fig. 6B, tlie Adder primitive 690 will not execute until it has all 
of the data from the OneTimeCharge 655, RecurringCharge 660, PeakStepRater 680 

20 and OfPealcStepRater 685 primitives. If there is no data available from those 
primitives, such as in the case where there is no longer a one time chai-ge, an 
appropriate signal such as a "0'' null data is sent from the primitive. In one 
embodiment, primitives ai'e grapliical icons used in data flow programming. In tliis 
embodiment, building a price plan creates soui'ce code for a graphical programming 

25 environment such as Visio®. 

Fig. 6C is a screen shot of an implementation of a price plan builder using a 
Visio® environment. In tliis implementation, the Visio® environment is used to 
develop the gi*aphical programming necessarj' to build the price plan. A series of 
primitives 697 are placed in an editing field 699 and connected with a series of data 
30 flow connectors .697a. Palette tools 696 are used to build the graphical progi-am. 
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Also shown in the screen shot is an informational field 698 that is used to provide 
information about a higlilighted primitive. 

Primitives can also be created for a variety of puiposes such as monitoring the 
incoming data from the collector 235 to make sure that the client 210 is not using the 
5 network connection for any unauthorized purposes. For example, if the client 210 is 
paying only for time-based usage, tlien it is inappropriate to connect a sei-ver and use a 
disproportionate amount of bandwidth. An implementation of a piiiiutive can check 
the amount of bandwidth a client 210 is using and compare it with the price plan. 

In order to assure accuracy of the price plan and ultimate billing, the price plan 
1 0 wizard or a similar template can be used to test the price plan with known data. Price 
plan object code is tlien available in the price plan database 410 for execution. Wlien 
retrieved for execution tlie developer can run the code in a run time diagnostic 
environment with Icnown data with loiowledge of charges tlie result. In this way, the 
developer can run diagnostic data to check the accuracy of the code before it is 
1 5 compiled to object code and used in an actual billing environment. 

Fig. 7 A illustrates a flow chart of an implementation of diagnostic data 
process. The code stored in the price plan database 410 is retrieved 705. The 
developer then deteimines 710 if there are any modifications necessai-y in the code. 
In the fu'st instance of retrieving die code, there are typically no modifications that aie 

20 necessary and the developer has made the determination that the test code is to be 
tested 715. The developer can tlien use the testing run time envii-onment to test tlie 
source code witli Icnown data by stepping 720 tluxjugh the code. Thereafter, the 
developer can determine 710 once again if there are any modifications to be made. If 
there are modifications, then the developer makes those modifications. Typical 

25 modifications can be but are not limited to adding 730 a new processes (or 

primitives), modifying 735 existing processes (existmg primitives can be modified but 
involve more complicated softwai*e programming) and modifying 740 the cormections 
between processes (primitives). Typical modifications can be but ai*e not limited to 
addmg 730 a new process (or primitive), modifying 735 the property (or data) with 

30 existing processes and modifying 740 the connections between primitives. 
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Once a price plan has been built and tested, it is stored in the rating database 
410. In a typical embodiment, the price plan is stored as extensible markup language 
(XML). When a price plaii is programmed and stored, it is subsequently retrieved and 
compiled into object code for execution by tlie rating engine 340, Fig. 7B illustrates a 
5 flow chart of an implementation of a price plan object builder. To compile the 
grapliical source code, the XML price plan code is obtamed 755 from tiie plan 
database 410. The XML code is parsed 760 to create an object representation of tlie 
code. At this time it is determined 765 if there are anymore processes that ai*e to be in 
the plan. If more processes ai'e desired in the plan, the developer can find and load 

10 770 the primitives from the primitive database 420 and object representations of those 
primitives are created 775. Properties of the object primitives are established 780 
such as by furnishing specific data (i.e., constants or multipliers are indicated in Table 
1.) If tliere are no more rating processes to be added to the plan, then the compilation 
process establishes 790 the interconnections between the primitives. At tliis point, the 

15 fauh tolerance discussed above is built into the code. He execution sequence of the 
rating primitives as discussed above is detennined. Each primitive is progi*ammed to 
''Icnow" tlie data for which it has to wait before executing. The plan semantics ai^e 
then vahdated 795, for example, any specific provisions in the plan. The object code 
is then delivered 796 to the rating engine 340 for execution. 

20 Fig. 8 illustrates a flow chart for an hnplementation of a rating engine 340 

object code execution process. When the code is executed, the rating engine 340 is 
told to retrieve 805 a usage record. This record is the usage data gatliered by tlie 
collector 235. The rating engine 340 then retrieves 810 usage record account 
information from the accoiuit management module 255 or the account database 370 in 

25 order to determine what plan is to be used. The rating engine 340 then retrieves 8.15 
the plan ID for a record and date. Tlie plan logistics may differ for different usage 
records and dates. The rating engine 340 determines 820 if the object code identified 
by tlie plan ED is available in a code cache for execution. If tlie object code is not 
available, then the proper primitive comiections are established 850 (same as 

30 establishing 790 piimitive interconnections in Fig. 7B). If the object code is not 

available, then the object code is constructed and delivered (Fig. 7B). Once the code 

is available, then the code is initialized 825 with the pertinent variables from tlie 
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account information (i.e., rates, free-usage etc.) The usage record is then rated 830 
appropriately based on tlie plan and the account variables are updated 835. The bill 
data is tlien output 840 to the bill details database 380. Tins process is repeated for ail 
data records retrieved by the collector 23 5 . 

5 

Bill Presentation 

Refening again to Fig. 3, the bill presentation template 320 and the web bill 
presentment are typically embodied, respectively, in a web page dehvered to the 
client's browser 330. In one embodiment, a bill presentation web page (not shown) is 

10 typically created and modified by using a HyperText Markup Language (HTML) 
editor. The HTML editor allows the service provider 230 and/or the client 210 to 
create a web page that best meets the needs in bill presentation. The sei-vice provider 
230 provides elements that are important to tlie bill presentation process such as the 
separate charges incurred during the billing cycle. The client 210 can optionally add 

1 5 biUing data and the order in which it is presented. For example, the client can present 
tlie incurred charges and the raw usage-data side by side to check on the accuracy of 
the charges. Tlie client can also add tlie terms of the billing plan as a reminder of how 
chai'ges are incurred. If tlie client 21 0 is signed up to use multiple billing plans, the 
charges for all tlie plans can be displayed side by side to provide a price comparison 

20 so that the client can ultimately choose the price plan of choice. 

Fig. 9 is a flow chail of an implementation of a bill presentment process. 
When the client 210 malces a request to view billing information on tlie client browser 
330, the service provider 230 sends 905 a web page, as an HTML file, to the client's 
browser 330. The client can, at anytime during the process, for example, make 935 

25 modifications to tlie web page to customize the page to meet the client's 210 needs. 
The service provider 230 provides 910 the billing data from tlie billing details 
database 380. If there is a network connection, the service provider 230 can also 
provide 915 any real time data as the rating engine 340 produces it The HTML file is 
then formatted 920 to display the data to the client 210. As the client 210 is viewing 

30 the web page, it is detennined 925 whether or not tliere is more real data available. If 
there is more real time data, then it is provided 915 to the client's browser 330. The 
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process is repeated as necessary. The information is all output 930 as an HTML file 
for viewing by the client 210. 

Fig. IDA is a screen shot of an implementation of a bill presentation template 
1000. This template is used as a development tool for the actual bill presentation that 

5 the client 210 sees. The figure iUustrates that the template 1 000 is displayed on a 
typical web page 1005. The template 1000 contains vaiious fields as described above. 
A field 1010 for a one time installation cost is first shown. This field will typically be 
present only the first time the template 1000 is displayed to the client 210. In tliis 
particular price plan, the client 2 10 is using a price plan that includes charges for web 

1 0 space used and email. Respective fields 1 0 1 5 , 1 020 are displayed in the template 
1000 to reflect these charges. Fields 1025, 1035 are displayed for on and off peak 
charges. Respective fields 1030, 1040 are displayed reflecting tlie number of hours 
connected for on and off peak. Further chai'ges present in tlie billing plan are an FTP 
data transfer charge and a Voice over IP data charge. Respective fields 1045, 1055 

1 5 reflect these charges, and fields 1050, 1060 reflect the amount of data transferred to 
incur those charges. 

Fig. lOB illustrates a screen shot of an implementation of the bill presentation 
template 1000 after it has been filled with billing data. The template 1 1 00, as seen by 
the client 210, contams a field 1110 for tire billing period, as well as a field 1 120 
20 displaying the total costs. The fields 1130 as discussed with respect to Fig. lOA are 
filled with the actual billing data. Several additional fields can be added to reflect 
other charges that are inciuTCd using other price plans. Figs. 1 OA and lOB are used 
only as examples of the types of templates that can be used in botli bill presentation 
development and an actual bill presentation. 

25 The teclmiques and apparatus discussed above have several business 

applications. In a typical application, as discussed above, price plans are developed 
by an ISP or NSP to meet the needs of different types of clients with different needs. 
In addition, the ISP or NSP v^ll be able to achieve maximum charges from the cUents 
commensurate with their use of tlie network. For example, if a chent is attaching a 

30 server diat uses a lot of bandv^ddth, the ISP or NSP is able to detect that used 
bandwidth and make an appropriate chai-ge. 
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In another embodiment, the customer accounts can be pailitioned according to 
account numbers. For example, if there are one million customer accounts, 10 
paititions can be created by assigning account numbers 1 to 100,000 to the first 
partition, 100,001 to 200,000 to the second partition and so forth. A rating engine is 

5 then assigned to each partition. The rating engine selects and rates usage records witli 
the assigned account number range. Scalability is acliieved by creating the proper 
number of paititions with corresponding rating engines and distributing the rating 
engines to multiple computers. By assigning account number ranges to rating engines 
instead of having rating engines to process arbitrary accounts, caching of account 

10 information is possible (since no other modifications are made to the same account) 
and thereby increase the overall usage record processing rate. 

In another embodiment, more tlian one engine can be assigned to work on the 
same account partition. In such a case, each engme working on tlie same paitition is 
assigned a unique priority. The rating engine with tlie highest priority is active 

15 processing usage records. Otlier engines are monitoring tlie status of tlie active 
engine. In the event that the monitoring engines detect inactivity of the primary 
engine, the next liighest priority engines takes over processing die usage records. Tlie 
active engine updates a record in the database with a current time stamp. IF the time 
stamp fails to be updates, the active engine is assumed to be non-fiinctional. A 

20 monitoring engine initiates a talce over procedure. When the failed engine recovers, it 
regains control from a lower priority engine and resumes processing of the usage 
records. No central controlling entit)^ is involved in the fail otlier that the database. 
Each engine operates autonomously. 

Various aspects of tlie tecliniques and apparatus may be implemented in 
25 digital ckcuitry, or m computer hardwai*e, finnware, software, or in combinations of 
them. Apparatus of the invention may be implemented in a computer products 
tangibly embodied in a machine-readable storage device for execution by a 
programmable processor. The foregoing techniques may be performed, for example, 
by a programmable processor executing a program of instructions to perform 
30 ftmctions of the invention by operating on input data and generating output. The 

methods may advantageously be implemented in one or more computer programs that 
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are executable on a programmable system including at least one programmable 
processor coupled to receive data and instructions from, and to transmit data and 
instructions to, a data storage system, at least one in/out device, and at least one 
output device. Each computer program may be implemented in a high-level 

5 proceduial or object-oriented programming language, or in assembly or machine 
language if desii-ed; and in any case, the language may be compiled or interpreted 
language. Suitable processors include, by way of example, both general and special 
purpose microprocessors. Generally, a processor will receive instructions and data 
from read-only memory and/or random access memor>^ Storage devices suitable for 

10 tangibly embodying computer program instructions and data include all forms of non- 
volatile memory, including by way of example, semiconductor devices, such as 
EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard 
disks and removable disks; magneto-optical disks; and CD-ROM disks. Any of the 
foregoing may be supplemented by or incorporated in, specially designed appUcation- 

15 specific integrated circuits (ASICS). 

A nmnber of embodiments of tlie invention have been described. Nevertheless, 
it will be understood that various modifications may be made without depaitmg from 
the spirit and scope of the invention. Accordingly, otlier embodiments are within the 
scope of the following claims. 

20 
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What is claimed is: 

1 . A metliod of determining a billing-cycle price for netH'ork services, 
comprising: 

5 using a plm*ality of graphical elements on a display to establish a price plan for 

each of a plurality of clients, wherein the price plan sets a price per use unit; 

collecting use data from the plui-ality of clients; 

sorting the use data into data groups corresponding to each of the plurality of 
clients; and 

10 using the graphical elements to process the data gi'oups to determine the 

billing-cycle price for each of the plui'ality of clients, wherein the bilUiigrcycle price is 
calculated from use data and the price per use unit. 

2. The method of claim 1 wherein the price per use unit is determined by time 
15 that each of the clients used tlie network services. 

3 . . The method of claim 1 wherein the price per use unit is detemmed by 
network bandwidth that each of the clients used. 

20 4. The method of claim 1 wherein the price per use unit is determined by 
network content that each of the clients used. 

5. The method of claim 1 wherein the price per use unit is determined by email 
diat each of the clients generated on the network, 

6. The method of claim 1 wherein the price per use unit is determined by 
electronic storage space used by each of the clients. 
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7. The metliod of claim 1 wherein the price per use unit is determined by web 
space that each of tlie cHents used. 

8. The method of claim 1 wherein the price per use unit is determined by 
5 multimedia usage tliat each of the clients used. 

9. The method of claim 1 wherein the price per use unit is determined by Internet 
protocol addresses in use by each of the clients. 

10 10. The method of claim 1 fiulher comprising: 

allowing each of the piuiality of clients to choose a price plan that includes 
more than one price per use unit; 

calculating a billing-cycle price for each price per use unit; 

presenting each bilhng-cycle price to each of the clients; and 

1 5 allowing the client to choose the billing-cycle price tliat is the most cost 

efficient. 

1 1 . The method of claim 1 further comprising: 

comparing a cost associated witli the plan to the billing cycle price; 
20 determining a profit of each of a plurality of price plans; and 

determining an action to increase the proj5t. 

12. The method of claim 1 1 wherein tlie action is changmg one or more of the 
plurality of clients to a new price plan. 

25 



13. The method of claim 1 1 wherein tlae action is eliminating one or more of the 
price plans. 
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14. The method of claim 1 further comprising: 
developing a new price plan; and 

using a set of old use-based data in the new price plan to determine an effect 
5 on profits. 

15. The method of claim 1 further comprising: 

transmitting a bill presentation template to each of tlie clients. 

16. The method of claim 15 wherein the bill presentation template is transmitted 
10 to a client web browser connected to the network. 

17. The method of claim 16 wherein the bill presentation template displays 
charges incurred during the billing cycle. 

15 18. A method of developing a price plan for services on a display, comprising: 
providing an interface on the display; 

providing on the interface images adapted to receive price plan criteria; and 
receiving in the images price plan criteria. 

20 19. The method of claim 1 8 wherein images on the interface are graphical user 
interface (GUI) screens. 

20. The method of claim 19 wherein providing the images comprises presenting 
the GUI screens in an order to present price plan criteria input options for generating 
25 the price plan to the user. 



21. 



The method of claim 20 further comprismg: 
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generating tlie price plan into source code; 

compiling the computer code into machine-readable code. 

22. The method of claim 21 further comprising: 

5 supplying the price plan data to at least one of the soui'ce code and the 

macliine-readable code to calculate a charge for the services. 

23. The method of clauTi 1 8 wherein tlie images on the interface are graphical 
elements representing components of the price plan. 

10 

24. The method of claim 23 wherein providing the images comprises: 

airaiiging the grapliical elements on the display that graphically represents the 
calculations for the price plan charge; and 

proAdding interconnections among the graphical elements to provide price plan 
15 data flow paths. 

25 . The method of claim 24 fuitlier comprising: 

storing the arrangement of graphical elements as source code; and 
compiling the source code into machine-readable code. 

20 

26. The method of claim 25 fiirther comprising: 

supplying the price plan data to at least one of tlie source code and the 
macliine-readable code to calculate a charge for the sendees. 

25 27, A method of billing for services, comprising: 

graphically determining a price plan that charges a client for services based on 

use; 

27 
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keeping a record of data of the client's use of the services; 

determining a charge for the semces based on the price plan and the record of 
the client's use of services; and 

presenting a bill for die semces. 

5 

28. Tlie method of claim 27 wherein determining the price plan comprises: 
establishing the type of use for wliich the client desires to be billed; 
establishing a unit of cost for the type of use; and 

generating a customized price plan template that reflects the type of use and 
1 0 the imit of cost and is adapted to receive the record of data. 

29. Tlie method of claim 28 wherein determining the charge for the services, 
comprises using tlie customized price plan template to calculate the service chai*ge by 
processing tlie record of data based on the type of use and the unit of cost. 

15 

30. The method of claim 28 wherein presenting the bill for services comprises: 

generating a bill presentment template adapted to present the record of data, 
the type of use, the unit of cost, and the service charge; and 

presentmg the bill presentment template to the cUent. 

20 

31. A price plan network system, comprismg: 

at least one data collector adapted to collected client data from the network; 
a database coupled to tlie data collector; 

a price plan builder coupled to the database, the price plan builder having: 

25 a user interface; 

a fu-st software module having a price plan template adapted to direct a 
user through a series of steps to develop a price plan; 

28 
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a second software module coupled to the fust software module, the 
second module including a piiu*ality of components adapted to be 
interconnected to build a price plan source code; 

an object builder adapted to compile tlie source code into machine readable 
5 code; and 

a bill presentation module coupled to the database. 

32. The system of claim 31 fuither comprising a rater coupled to tlie database, 
adapted to be conti'oUed by the machine-readable code to process the client data into 

10 billing data. 

33. The system of claim 32 further comprising at least one additional rater, 
wherein the rater and the at least one additional rater are adapted to operate 
autonomously of each other, and fuiiher adapted to monitor each otlaer for failure, and 

15 to operate in the event that one of the rater and the at least one additional rater fail to 
operate. 

34. The system of claim 32 wherein the bill presentation template comprises a 
user interface adapted to display the client data and tlie billing data. 

20 

35. A price plan development and presentation system comprising: 
means for building a price plan based on a client's use of services; 
means for collecting raw use-based client data; 

means for processing the use-based chent data using the price plan; and 
25 means for presenting the raw and processed use-based client data to the client. 



36. A network service provider method of charging a client for comiecting tlie 
client to the network comprising: 

29 
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developing a price plan agreement between tlie service provider and client, the 
agreement stating that the service provider provides a comiection to the network in 
exchange for compensation from the client, tlie compensation beuig calculated based 
on the client's use of the network; 
5 providing to the client a connection to the network; 

collecting use-based data from tlie network; 

processing the use-based data based on the price plan; and 

presenting the charges to the client. 

10 37 . A method of creating a price plan in a graphical program on a computer 
having a memorj', a display, a user input and a processor, comprising: 

storing in memory a plurality of executable fiinctions representmg aspects of 
tlie price plan; 

assembling a data flow diagram on the display in response to user input to 
15 specify the price plan, the data flow diagram including function icons con*esponding 
to the respective ones of the executable functions; and 

generating an executable program from tlie data flow diagram. 

38. The method of claim 37, further comprising: 

20 receiving price plan data in tlie executable program; 

processing the price plan data to calculate charge output data. 

39. The method of claim 38 fuitlier comprising: 

creating a bill presentation template on a web page; and 
25 providing the charge output data to the bill presentation template. 
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